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REMARKS 

In response to the Office Action mailed on September 24, 2008, Applicant 
respectfully requests reconsideration. Claims 1-28, 30, and 31 are pending in 
this application. Claims 1-7, 11, 14-21, 25, 28, 30, and 31 are rejected. Claims 
8-10, 12, 13, 22-24, 26, and 27 contain allowable subject matter, but are objected 
to as being in dependent form. In this reply, no claims are being amended as 
Applicant respectfully submits the claims include limitations not taught or 
suggested by the cited prior art. 

Claims 1,15, 30, and 31 are independent claims, and the remaining 
claims are dependent claims. Applicant believes that the claims as presented 
are in condition for allowance. A notice to this affect is respectfully requested. 

Applicant respectfully requests close attention to the following 
independent and dependent claims most likely to be subject of an on appeal. 

Rejections under 35 U.S.C. § 102 

Claims 1-7, 11, 14-21, 25, 28, and 30 have been rejected under 35 U.S.C. 
§102 as being anticipated by Gerard et al. (US 6,023,704). A claim is anticipated 
only if each and every element as set forth in the claim is found, either expressly 
or inherently described, in a single prior art reference . M.P.E.P. 2131 . Applicant 
respectfully traverses the rejection because Gerard fails describe each and every 
element as set forth in the claims. 

Claim 1. 

Claim 1 recites: 

1 . (Original) A method for processing client requests supporting a plurality of 
object models, the method comprising: 
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receiving a former client request requiring access to a former object 
defined by a former object model; 

mapping a former object required for access by the former client request 
to a corresponding current object existing within a current object model; 

copying current object data within the current object of the current object 
model to former object data within an instantiation of the former object; 
and 

processing the former client request using the instantiation of the former 
object to satisfy the former client request. 

Applicant respectfully submits that Gerard fails to describe "copying 
current object data within the current object of the current object model to former 
object data within an instantiation of the former object." This is a step in a 
backwards compatibility process. Current object data is copied into former object 
data within an instantiation of the former object. In other words, the method 
converts current data to old data. The Office Action asserts that Gerard 
teaches this limitation in column 2, lines 58-60: "and reading and converting the 
state data of the old object (now the second object) into the new object (now 
the first object)." In other words, Gerard teaches converting the old object into 
the new object. This is the opposite of the limitation in claim 1 . Thus, Gerard 
teaches the opposite of the claim limitation, and therefore Gerard fails to describe 
this limitation. 

Additionally, Applicant respectfully submits that Gerard fails to describe 
"receiving a former client request requiring access to a former object defined by a 
former object model." The Office Action asserts that Gerard describes this 

limitation in column 3, lines 50-52, and at column 4, lines 5-7. In the column 3 
citation, Gerard reads: "Each object is an identifiable, encapsulated piece of code 
and data that provides one or more services when requested by a client." In the 
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column 4 citation Gerard reads: "The server object receives and interprets tine 
message, and can then decide what operations to perform." 

In other words, Gerard teaches services requested by a client, and 
teaches receiving messages. Gerard does not explicitly teach the claim 
limitation. This section of Gerard describes an overview of object-oriented 
technology. Gerard is silent on receiving client requests requiring access to a 
former object defined by a former object model. 

The Office Action also asserts that "former" and "current" is equated to be 
the same as "first" and "new second" as stated by Gerard. Applicant respectfully 
disagrees. The term "former" has more than one meaning. One meaning is 
"occurring in the past," and another meaning is "preceding in place or 
arrangement." (Merriam-Webster Online Dictionary. 2008. Merriam-Webster 
Online. 3 November 2008, www.merriam-webster.com/dictionary/former.) The 
claim language of claim 1 clearly identifies which definition is used. When 
"former" means "preceding in place or arrangement," typically the word "latter" is 
used in conjunction with former. When "former" means "occurring in the past," 
typically the word "current" is used in conjunction with former. Claim 1 uses the 
terms "former" and "current." In this sense, Gerard does not teach receiving a 
former client request requiring access to a former object defined by a former 
object model. 

The method of processing client requests according to claim 1 means that 
the claimed method provides backwards compatibility even though the current 
object model is not directly backward compatible. This backward compatibility is 
for applications that access a changing object model. Gerard does not provide 
this benefit. Gerard only discusses changing or updating an object model without 
shutting down a system. 
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Accordingiy, Applicant respectfully submits that claim 1 is in condition for 
allowance. Applicant respectfully requests the rejection under 35 U.S.C. §102 be 

withdrawn. 

Claims 15 and 30. 

Applicant respectfully submits that independent claims 15 and 30 are not 
anticipated by Gerard. Claim 1 is a process claim. Claims 15 and 30 are 
product/manufacture claims that claim similar subject matter as claimed in claim 
1 . For applicable reasons from the discussion of claim 1 , Applicant respectfully 
submits that claims 15 and 30, likewise, are not anticipated by Gerard. Applicant 
respectfully requests that the rejection under 35 U.S.C. §102 be withdrawn. 

Further Distinctions 

Note that several of the dependent claims recite further patentable 

distinctions over the cited prior art for consideration. Applicant respectfully 
requests close attention to the following dependent claims, namely claims 3, 5, 7, 
and 11. 

Claim 3. 

3. (Original) The method of claim 2 wherein exposing a former service interface 
for use by former clients for receipt of former client requests comprises: 

providing a former remote method invocation interface for former clients to 
use to provide former client requests for processing; and 

concurrently providing a current remote method invocation interface for 
current clients to use to provide current client requests for processing. 

Claim 3 recites: "providing a former remote method invocation interface for 
former clients to use to provide former client requests for processing." The Office 
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Action asserts that Gerard teaches this limitation in column 3, line 65-column 4, 
line 7. The cited section of Gerard reads "the object system isolates the 
requestor of services... by a well defined encapsulating interface" and "the server 
object receives and interprets the message." The encapsulating interface of 
Gerard is no more than a regular interface for receiving requests. Gerard 
discusses this interface in the overview section of object-oriented technology, 
and thus describes no more than a conventional interface used with requestors. 
Gerard is silent on exposing a former remote method invocation interface for use 
with former clients. 

Additionally, claim 3 recites: "concurrently providing a current remote 
method invocation interface for current clients to use to provide current client 
requests for processing." In other words, two interfaces are provided 
simultaneously— one interface for former client requests, and one interface for 
current client requests. The Office Action asserts that Gerard teaches this in 
column 8, lines 3-13. This section of Gerard describes what Gerard does after 
swapping data of first and second objects, in that Gerard completes the 
transformation of data without disturbing the identity of an object defined by an 
object header. Gerard is silent on concurrent or simultaneous remote invocation 
interfaces with one interface for former client requests and one interface for 
current client requests. Because Gerard fails to describe each and every 
limitation of claim 3, Applicant respectfully submits that claim 3 is not anticipated 
by Gerard. Applicant respectfully requests that the rejection under 35 U.S.C. 
§102 for claim 3 be withdrawn. 

Claim 5. 

5. (Original) The method of claim 4 wherein: 

the former object and current object are defined in an object-oriented 
programming language; and 

wherein obtaining a former object definition comprises: 
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using a reflection technique to identify, from a former object model 
definition file, the former object definition based on the identity of 
the former object specified within the former client request; and 

wherein instantiating the former object within a memory system 

comprises: 

using a former object class loader to load the former object 
definition, identified in the former object definition file, into the 
memory system as an instantiation of the former object. 

Specifically, claim 5 recites: "wherein obtaining a former object definition 
comprises: using a reflection technique to identify, from a former object model 
definition file, the former object definition based on the identity of the former 
object specified within the former client request." For example, an embodiment 
could use Java reflection to identify the former object definition. The Office 
Action asserts that Gerard teaches this limitation in column 4, lines 3-5. The 
cited section reads: "The server object receives and interprets the message, and 
can then decide what operations to perform." Gerard discusses only receiving 
and interpreting messages, which is not a reflection technique used to obtain a 
former object definition model. The remaining specification of Gerard Is also 
silent on using reflection techniques. Furthermore, Gerard is silent on "definition 
file" and "object class loader" as claimed. Because Gerard fails to describe each 
and every limitation of claim 5, Applicant respectfully submits that claim 5 is not 
anticipated by Gerard. Applicant respectfully requests that the rejection under 35 
U.S.C. §102 for claim 5 be withdrawn. 

Claims 7 and 11. 

Claims 7 and 1 1 claim similar subject matter and so these claims are 
grouped together. 
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1 1 . (Original) The method of claim 1 wherein copying current object data within 
the current object of the current object model to former object data within an 
instantiation of the former object comprises: 

copying current object data values stored within current data fields of an 
instantiation of the current object to former data values within former data 
fields of an instantiation of the former object. 

The Office Action cites Gerard column 8, lines 3-15 to describe this 
limitation. As previously discussed, this section of Gerard describes what Gerard 
does after swapping data of first and second objects, in that Gerard completes 
the transformation of data without disturbing the identity of an object defined by 
an object header. Gerard is silent on current object data values stores within 
current data fields of an instantiation of the current object to former data values 
within former data fields of an instantiation of the former object. Because Gerard 
fails to describe each and every limitation of claim 1 1 , Applicant respectfully 
submits that claim 1 1 is not anticipated by Gerard. Applicant respectfully 
requests that the rejection under 35 U.S.G. §102 be withdrawn. 

Claim 31. 

Claim 31 has been rejected under 35 U.S.G. §102 as being anticipated by 
Halpern et al. (US 2003/0033442). Applicant respectfully submits that Halpern 
fails to anticipate claim 31 because Halpern fails to describes several limitations 

of claim 31. 

31 . (Previously Presented) A method for processing client requests supporting a 
plurality of object models, the method comprising: 

receiving a plurality of requests from former client versions requiring 
access to respective former objects defined by respective former object models, 
wherein the object models are shared object models; 
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exposing former service interfaces for use by former client versions for 
receipt of requests from former client versions; 

mapping former objects, required for access by tine requests from former 
client versions, to a corresponding current object existing within a current object 
model, wherein the current object model is a shared model, and wherein the 
current object model is not directly backwards compatible with the requests from 
former client versions; 

wherein mapping former objects further comprises indicating current 
objects that correspond to former objects defined in a former object definition file, 
and data within the current objects that correspond to data in the former objects; 

copying current object data from fields of the current object of the current 
object model to former object data within an instantiation of the former objects; 
and 

processing the requests from former client versions using the instantiation 
of the former objects to satisfy the former client requests, thereby providing 
backwards compatibility. 

Claim 31 recites: "copying current object data from fields of the current 
object of the current object model to former object data within an instantiation of 
the former objects." This is a step in a backwards compatibility process. Current 
object data is copied into former object data within an instantiation of the former 
object. In other words, the method converts current data to old data. The Office 
Action asserts that Halpern teaches this limitation in paragraph [0034] which 
reads: "It is a further objective of the present invention to store identification links 
that show the relationship of one class version to another." Halpern is a 
versioning invention that enables an operator to make changes while an 
application server continues running. In other words, Halpern maintains 
information about class versions. Claim 31 does not recite storing identification 
links to show class version relationships. Instead, claim 31 recites: "copying 
current object data from fields of the current object of the current object model to 
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former object data within an instantiation of the former objects." Thus, Halpern 
fails to teach this limitation. 

Claim 31 recites: "exposing former service interfaces for use by former 
client versions for receipt of requests from former client versions." The Office 
Action asserts that Halpern describes this limitation on page 2, paragraphs 
[0015]-[0016]. This section of Halpern describes interfaces similar to interfaces 
described by Gerard. The cited section of Halpern is located in the background 
section of Halpern's disclosure and focuses on giving background to object- 
oriented programming. Halpern thus describes no more than a conventional 
interface as part of an object-oriented programming environment. Halpern is 
silent on exposing an interface for use by former client versions for receipts of 
requests from former client versions. Thus, Halpern fails to teach this limitation. 

Claim 31 recites: "mapping former objects, required for access by the 
requests from former client versions, to a corresponding current object existing 
within a current object model, wherein the current object model is a shared 
model, and wherein the current object model is not directly backwards 
compatible with the requests from former client versions." The Office Action 
asserts that Halpern teaches this limitation in paragraph [0034] which reads: "It is 
a further objective of the present invention to store identification links that show 
the relationship of one class version to another." Halpern describes an objective 
to class version relationships, but fails to explicitly, or implicitly, describe mapping 
former objects, requests from former client versions, current object model is a 
shared model, the current object model is not directly backwards compatible with 
requests from former client versions. Therefore, Halpern fails to teach this 
limitation of claim 31. 
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Accordingiy, Applicant respectfully submits that claim 31 is in condition for 
allowance. Applicant respectfully requests the rejection under 35 U.S.C. §102 be 
withdrawn. 

Summary 

Applicants respectfully submit that the claims in the subject application are 
not anticipated by Gerard or Halpern because the prior art fails to teach or 
disclose each and every element of the claimed invention. Thus, Applicants 
submit that the pending claims are in condition for allowance. 

Applicant hereby petitions for any extension of time which is required to 
maintain the pendency of this case. If there is a fee occasioned by this 
response, including an extension fee, that is not covered by an enclosed check, 
please charge any deficiency to Deposit Account No. 50-3735 . 
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